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Editor Treasurer 
Harry Huggins Kon Allen 
12 Thomas Str. 2 Orlando str. 
Mitcham. 5152. Hampton. 3188, 
03-073 1408 05-598 4554 
Having seen the er... "MARVELS" of the ..er.. "PREMIER STATE", it is 


quite arelief to return to the "SANITY" of a less boastful locale now the 
finals fever is over! 

Still it was quite interesting to see the "PREMIUM" shortcomings of the 
adjoining state. In fact the only place I noticed Premium was on their 
number plates, and that has been deleted from the newer ones. They are 
learning! 


The computer show was quite interesting, and well worth attending. On 
display was the whole range of computers, from the mighty VZ to the "run of 
the mill" IBM. The VZ was the only one I noted doing "something new". This 
was in several fields, such as the Analog joystick, a mouse, speech synth., 
transmission of programs over phone lines with serial interface and modem, 
a very accurate capacitance meter and an ohm meter,making use of the VZ's 
(as yet not fully utilise) powers. These were further demonstrated at the 
HVVZUG meeting on Sth Oct., at which I was warmly welcomed. 

I have been assured that in due course all these will appear in the 
HVVZUG newsletter, and maybe we will be permitted to copy them. 

I do however return with several programs that will interest our next 
meeting. 


The other computers were doing their usual stunts, Databases, Spread 
Sheets and Wordprocessors. The Commodores and Ataris were playing games at 
which they are so good. Of note was a T.I. (Texes Instruments) controllig a 
model train, entirely from a program. | 


I make mention of David's article, and I also mention details at end of 
Games Column. It is quite an effort, and we would like to see more like it. 
How about it members? 


Meetings are held on the first Sunday of each month, now at 12 THOMAS 
STR. MITCHAM. Any time after midday is a good time to turn up. 


Last issue, in Letter to the Editor, the Data statements were missed 
out. You will find them in The Hhackers Column. Sorry about that. I was 
expecting another letter to editor this month, but it did'nt arrive. Also 
looking forward to another SCREAM SHEET. The author should be well equiped 
now to really get down to "DEAR HARRY" 


A MERRY CHRISTMAS to you all, апа а very satisfactory New YEAR. 
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By DAVID WOOD 


If you have never written an adventure program before, it isn’t as hard as it 
seems. It’s true that adventure programs are very long, and take a long time to 
prepare and type in, but most of the actual program coding isn’t all that 
difficult. The more complicated pieces of programming, like the sections of the 
program that display room descriptions and contents, or allow the computer to 
understand what the player types in, don't vary much from program to program, and 
can be copied when you come to write a program of your own. 

There may be some of you that have never played an adventure game before. If 
you haven't, there are some good programs available on VZ Down Under's Public 
Domain tape #1, with a few other good adventures on the other tapes. There have 
also been a few adventure programs published in this magazine - 'The Thief of 
Baghdad’ (VZDU #1), ’Silver Mountain’ (VZDU #4 — VZDU #9) and 'Merkfruit lodge’ 
(VZDU #23). | 

With this is a sample adventure program for you to type in. it is 
comparatively short, but it still won't quite fit into an unexpanded VZSOO. It 
will fit if the following lines are deleted: 
1130,1140,1160,1170,1180. 

Unfortunately, when we try to add a few extras to the program, like saving and 
loading of the players progress in the game so far and longer room descriptions, 
you won't be able to add these. 

The saving/loading routines mentioned above haven't been included at this 
stage, because the PRINTS routine doesn’t work for all types of datasette! The 
routines used are quite complex and so will be discussed in a separate article. 
They are based on the memory dump article in VZDU #7, so enthusiastic tape users, 
or disk users, can add their own routines if they want to. 

This program won't be available as public domain software as the second best 
way to learn how to write an adventure program is to type one in. (The best way to 
learn is to write опе yourself!). It may be made available on a swap basis for 
other adventures, but I haven't organised anything about this yet. 

If you want to enjoy playing this game, type it in fairly soon as we will look 
at the program in detail in later editions - this may give too many clues on how 
to solve it! Type the program in very carefully as small bugs (mistakes) can take 
ages to track down. As soon as you get tired or grumpy, STOP, save your program 
to tape or disk, and resume typing it in later on. Save the program before running 
it for the first time, as it has some machine code routines in it, which could 
make the program crash if there are any mistakes in them. 

Lastly, if you have any problems understanding this, or any other of these 
articles, please write to me at: 


RMB 1815 
Samaria Rd 
Benalla Vic 3673. 


I will reply to all correspondence eventually, but this may take some time as 
I am doing year 12, and homework commitments must come first. 
the first real article will appear in the next edition. 


М 


There are several ways to design an adventure game. The method described in this 
and the next few articles is the one I personally use, but this doesn't mean it is the 


"right" way. If you prefer to use a different method of design, or programming fov that 
matter, then do so. 

Firstly think of an object for the game - a setting for it to take place in and 
some major task for the player to perform. Common goals of adventure games are to 
collect some treasure, to escape from somewhere, to rescue one or more people, to solve 
a mystery, to lift a curse, or to save life on earth as we know it from total 
destruction, just to name a few. The setting can be in the past, the present or the 
future - in space, in a magical land ov an ordinary building. To summarise, the only 
limit on tasks or settings is your own imagination. 

You then think of a character to be controlled by the player. Try to make it fit in 
with the setting of the game. A barbarian hero would be well suited to a "Sword and 
Sorcery" type game but would be rather out of place in a space adventure. 

If you can't think of a character or setting for your adventure, try stealing one! 
Books, television and films could be used for this. You can always change the names of 
them later on when you have got a few more ideas. (If you use the original names, there 
could be a few copyright problems if you try to sell the game, but it is OK if you only 
plan to write the game for your own use.) Another approach you could use is to play a 
game from a different type of machine until you have solved it, then write it for the 
VZ from scratch. This was quite succesfully done by Scott Le Brun, who converted the 
game "King's Quest" for the VZ300, by completely rewriting the program code. The result 
was the program "Knight's Quest", which is considered to be one of the best adventures 
available for the expanded VZ300. There are more copyright restrictions with this 
method, and the usual problems with lack of memory space. 

Don’t waste time trying to think of something if you don’t feel like it. Games 
designed like this aren't usually successful. Wait for a while and you will probably 
think of something later on. 

Make sure the plot of your game is one you are interested in. It takes a long time 
to get from the design stage to the finished product, so if the game boves you, it is 
quite likely that you will give up. I have quite a few maps lying around at home, of 
adventures that never made it off the drawing board. 

Once you have thought of a setting, goal and character, you need to think of some 
other tasks and traps for your player before finishing the game. Completing the major 
task of the game should be the climax. This part should not be easy — it should require 
a burst of truly creative thinking. For example, if the object of the game is to 
destroy а malevolent robot, typing KILL/ SMASH/ DESTROY ROBOT should not work. Instead 
use something more imaginative. 
eg. 

The robot sees you and begins to lumber slowly towards you. 

What next? DROP BANANA PEEL 

The robot has tripped over the banana peel and crashes to the floor. 

You have angered the robot and he is about to struggle to his feet and 

throttle you. | 

What next? EXAMINE ROBOT 

There is a small slot in the back of his neck. 

What next? INSERT CARPET FLUFF 

The fluff has blown all his circuits and he now can't move a single 

motor. . 


To add to this when the player goes through rooms containing carpet fluff or banana 
peels, he/she is likely to consider them of questionable value and ignore them. Another 
method would be leave the banana skin around a banana, and the player would be tempted 
to eat the banana and throw the peel away. 

Once you have thought of a few tricks and traps, you should know if you program is 
going to work or not. If you can’t think of anything, it may be that your plot isn't 


feasible. You should be able to get some general ideas from playing other adventure 
games, but never take something directly from another one. If players have played this 
adventure before, they will know the solution to the problem straight away, which will 
make the game rather boring. (I have come across at least three adventures where you 
have to SPRAY bats or insects with an aerosol can.) Likewise, don’t repeat the same 
problem in the one adventure. 

Remember not to make the game so long that it won't fit in the available memory or 
too difficult to program. Don't make the game so complicated that the player has never 
seen anything like it before. Even though they want the game to be full ОҒ new and 
original puzzles, they want it to be at least partly familiar. (Most people only read 
a few different types of books, like spy stories or science fiction, but of course they 
don’t want each one to be exactly the same.) Also remember to not be so devious the 
player has го hope af solving the problem, and, of course, not make the game so easy 
that it is boring and will be solved in the first few attempts. There is a difference 
between being obvious and being comprehensible. Many commercial adventures state in 
their advertising that they will take many weeks to solve, and this is a major selling 
point. Don’t put too many braincrunching problems at the start of the game. Give the 
player a chance to explore and "become part of the game" first. While difficult 
problems are definitely needed, if they are placed ata stage before the player is 
"hooked" into the game, he/she will probably get frustrated and give up. 

You may like to place some random events in your program. If you do this, don' t use 
them to kill the player for no apparent reason. Instead use them to produce different 
secret passwords or combinations for each game, to randomly place an object that the 
player has to find (ora monster), or to help the player overcome a situation, like 
falling into a pit, where he/she would otherwise be killed. People who have played 
"Castle Greystone" would know that they have to kill zombies that appear at random 
around the castle with weapons that they may find in there. This is quite a reasonable 
use of random events, except that often zombies appear and kill players before they 
have had a chance to find a suitable weapon. 

If you have thought of a few problems but are stuck for a while, start drawing your 
adventure map and you will probably think of a few more ideas. When you have finished 
thinking up your plot, write down all of the object words the computer will need to 
understand. Sort these into lists of "gettable" objects (Objects the player can / is 
allowed to pick up and carry) and "ungettable" objects (objects that can't be picked up 
by the player). This is important because the computer needs to know where any por table 
object is at any one time. 

Some people think that any gettable object should have a use, but if the player 
realises this, he/she will know that they have to have every object at one stage Or 
another, and this would ruin the banana peel / carpet fluff effect described earlier. 

It is better to have some objects having uses, some having negative effects (like a 
box of gunpowder that explodes and does you grievous bodily harm every time you go into 
a room with a fire in it), and some that don't have any use at all, except to confuse 
the player ("How am I supposed to unbolt that useful looking sword from off the wall, 
and do I really need a broken left handed Farenheit scale thermometer?"). 

Next make up a list of verbs for the player to use as input. Common verbs include 
N,S,W,E (these are single letter abbreviations for the direction comands north, south, 
east and west), HELP (lists all the verbs the computer knows), INV (lists what the 
player is carrying), GET, LOOK, EXAMINE, OPEN, LEAVE, DROP, UNLOCK,LIGHT, etc. The HELP 
command is added because the player should have enough problems as it is, without 
having to work out what word to use. There is very little more frustrating than than 
knowing exactly what to do, but not knowing what word to use. If the correct words for 
a situation is "SCALE ROPE" and the player types "CLIMB ROPE", the computer will 
probably respond with something like "YOU CAN? T DO THAT." The most obvious reaction 
from the player is to assume that the rope can't be climbed, rather than rush down to 
the bookshop and buy the latest Thesaurus. The fact is that different writers use 
different words for the same situation. In two different adventures I have played, one 


insisted that you don't PUSH boats - you have to LAUNCH them. The other didn't 
understand what I meant by "LAUNCH," but responded perfectly when I told it to PUSH the 
boat. Опе exception to listing all your words is that if you have any words that would 
make an action rather obvious, like "VACUUM CARPET", you may prefer not to list them, 
but make the words fairly usual, and tell the player that some words have been omitted. 

You might like to include two words for the same action, so there aren't as many 
occurrences of "YOU CAN’T DO THAT" or "I DON’T UNDERSTAND". examples of this are "LOOK" 
and "EXAMINE", or  "UNLIGHT" and "EXTINGUISH" (UNLIGHT isn't a real word, but not many 
people like typing or spelling big long words like EXTINGUISH). You might also like to 
Give them slightly different meanings. "LEAVE" and "DROP" could have the same functions 
except things that are DROPped are more likely to smash, splatt, grow little green legs 
and run away, etc. Avoid using words like "USE" or "KILL" - make the player be more 
specific. 

When you come to the stage where you are about to design your map, decide how many 
rooms you are going to have, and draw up a grid of appropriate size. If you want to 
have 64 rooms make the grid 8 x 8 squares wide, or if you want 80 rooms make it 8 x 10 
squares wide, for example. The number of rooms depends on imagination and memory space. 
You don't have to use a grid, but make sure there is no more than one exit from a room 
in any direction - for example don’t have a room with two exits to the south, both of 
which lead to different rooms, or things get rather confusing. (Locations in adventure 
games are generally referred to as "rooms" even though they may not be - they could be 
parts of real rooms, somewhere out in the garden or in a forest.) Make each square have 
side length of 2 to 30 millimetres - an inch to a little bit over an inch for the 
nonc metric minded - although you might need to make them smaller if you want the map to 
fit on one page. Draw your map in pencil at first because you may make some mistakes, 
decide that you don't want to use a part that you have already drawn in, or suddenly 
think of something that would make your game much more interesting, only to find you 
don't have enough space for it on your map and have to either:- 

Xthrow your old map in the bin and start again. 
Xleave out the idea. 

You then decide where you are going to place your player at the start of the 
adventure. If it is taking place in a house, a logical starting point is in the garden, 
in one of the outside squares. Pencil in short descriptions for other rooms next. They 
don't have to be literary masterpieces - a few words for each room, like "bedroom", 
"entrance hall", or "room with locked door", will do at this stage. Draw in walls for 
every exit that the player can't move through. This is usually a double line drawn 
around the boundary of the map any anywhere else you decide is impenetrable. (Again, 
these are referred to as "walls", although they could be a tall and thick hedge, a rock 
fall or a cliff face.) Next place a number in the top left hand corner of each 
square, moving from left to right, and top to bottom, starting at one, and ending at 
64, or 80, or however many squares you happen to have. The reason why we start at one, 
and not zero, will become apparent when we come to write the program. Many games which 
start the numbering at zero read the room descriptions from memory into a data array, 
which means that the room descriptions are then in two different places in the memory 
at once, which in the case of the VZ is an appalling waste of precious memory. When 
writing adventure games for the VZ there isn't very much memory to play around with. 

Next arrows are drawn in each square for the directions that the player can move 
whilst in the square, and these are labelled with "N","S","W" or "E". North is usually 
taken towards the top of the page. Following this you are ready to write down your 
"movement codes," which will be needed for the program. If your map is a grid system, 
for each room decide for north, south, west and east (in that order) if there is an 
exit in that direction, and write down a "O" if there is, and a "1" if there isn't. For 
example if in one room there are exits'to the south and east, but not to the north and 
west, the movement code for that room will be "1010". Make up a movement code for each 
room and write them down somewhere. If you aren't using a grid structure, use "OO" 
for any direction in which there is no exit, and the room number of the destination for 
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directions in which there are exits. (You should use a leading zero for rooms one to 
nine.) If for example there is a room with no exits to the south or east, an exit 
north to room 8, and an exit west to room 17 the movement code in this case would be 
"08001700". This is where the advantages of the grid system shows most. If you make a 
mistake with the movement codes, the player will find that they could move south to a 
room, and then move north again, to find that the old room has magically disappeared 
and been replace by another one, which is rather frustrating. mistakes in the movement 
codes using the grid system are more likely to be detected, and can be fixed up by the 
programmer before anyone else plays the game. 

Now you have finished the map, you can "play" your game - not on the computer of 
course, but on paper and in your mind. Wander around the locations, pick up any objects 
and try to complete the task you have set. You might discover that you have left out a 
verb that you need, or that you have hidden the key behind the impenetrable hedge, but 
you can’t cut through it because the whipper snipper is locked in the shed. It is much 
better to find this at an early stage such as this, where the mistake can easily be 
fixed, rather than discover it when the program is nearly up and running, where at 
worst you could have to redesign some of your plot and a lot of your program to remove 
the error. 

One problem that occurs with adventures, even for some of the larger and more 
expensive computers, is what governs the items the player can carry. Some allow the 
player to carry as many things as he or she likes, but often the number of items is 
unrealistic unless the player has about seventeen arms. Others allow the player to 
carry a set number of items. The problem with this becomes apparent if we consider an 
example from the demonstration adventure with this set of articles. Imagine that the 
player is only allowed to carry three things. This means that the player couldn't carry 
a key, a tape, a roll of sticky tape and a book at the same time, but could carry a 
large and very heavy rock, a fridge and a washing machine! 

There are at least two possible solutions to this problem: - 

- Provide the player with, or allow the player to find early on, something in 

which anything found can be carried. A bag, a box, a backpack or a wheelbarrow 

are all suitable. 
- Give each object a weight, and limit the weight a player can carry, rather 

than the number of objects. 
The weight limit could either be fixed, or be based on the strength of a player (if you 
decide to have a strength rating in your game) at the time an attempt is made to pick 
up an object. There is no need to use a particular scale, like kilograms or ounces. 
Just rate your lightest object(s) as 1 unit, and if you think something is roughly 3 
times as heavy, rate it as 3 units and so forth. Your scale doesn't need to be 
particularly accurate as long as it is reasonable. 

In the last paragraph, I mentioned a strength rating. Although I won't be writing a 
great deal on how to program characters for role playing games, these are some of the 
attributes you might like to include if you decide to create a role playing adventure. 


STRENGTH: This is by far the most important attribute in an adventure game, and one you 
should include even if you aren't writing a role playing adventure. Not only does it 
govern how much a player can carry, but it also indicates the player's general state of 
health. If the strength rating reaches zero, it's the end of the line for the player. 
When the player does something silly, like drink something poisonous, points can simply 
be deducted rather than respond "SORRY YOU'RE DEAD" each time a wrong action is carried 
out. Of course there will be times that the player will be killed independant of the 
strength rating, if he or she happens to fall off a ninety-nine foot cliff, for 
example. As time goes on, particularly if the player is carrying a lot of heavy things, 
the strength rating may drop due to tiredness. This can be cured by leaving some food 
around for the player to eat, or somewhere to sleep. (Originally the players state of 
health was indicated by a separate HEALTH rating, but both are now usually covered by 
the STRENGTH rating.) ^c 


SKILL: In role playing board games, this is important for it determines how well a blow 


is aimed, while strength determined how hard the monster is hit. In computer games, 
this rating could be also used to decide the result of an action where the player has 
to show some form of coordination, like firing a gun or swimming, for example. 
(Anbitious programmers could even include a short arcade game-type test of skill before 
the start of the game to give a representative skill rating.) 


HEIGHT and WEIGHT: The main uses of these are to determine whether players are big 
enough to carry certain objects (irrespective of strength), or if they can cross 
dangerous territory, or hide somewhere. Very few hobbits can use six foot swords, but 
they would have an advantage over: giants when crossing rotten wood bridges or hiding in 
hollow logs. | 


INTELLIGENCE: This is mostly used to determine the character type of a player during 
character generation, with wizards being generally more intelligent than barbarians. It 
also decides if the player can learn new skills during the game. 


MAGIC ABILITY: The name says it all. Some character types will be able to do magic, and 
others won't. 


WEALTH: Once again the name says it all. This is used not only to indicate a player's 
success, but also to allow the player to buy things he or she might need during the 
game. 


LUCK: This can be used to overcome situations when the player might otherwise be 
killed. One good method of testing a player's luck that I came across chooses a random 
number between one and ten, and compares it to the player's luck rating. If it is lower 
than the luck rating, the player survives and the luck rating is decreased by on e 
point. If mot, it’s the end for the player. Luck is only tested when the player does 
something stupid, and it gives the player a chance to survive. 


There are several methods of generating a character. 

- Have preset values for each attribute. This makes the game, along with non-role 
playing adventures useful only until it is completed, and then it is "dead." however 
this is by far the easiest situation to program, and if your program is good enough, 
this shouldn't matter. 

— Have several character types, each with their own attribute values. This gives 
several different situatons for your game. 

— Have the same situation as above, also give the player a number of modification 
points. with which (s)he can add points to the various ratings. Also allow the player 
to take some points off some ratings and add these to others. With this method you 
would also need a subroutine which prevents particular ratings going above or below 
maximum or minimum values, and another to change the character types if the ratings are 
changed drastically. 

— Have all ratings randomly generated. 

Before you are ready to type in the program, you should have all the computer 
responses to your verbs and nouns prepared. Anything the computer doesn’t understand 
will be covered by a few different "I DON'T UNDERSTAND 'SMASH'" or "TRY SOMETHING ELSE" 
messages. Just make sure you make it clear what it is that the computer doesn't 
understand. There should also be a general message for situations where "YOU DON’T HAVE 
THE BUCKET" (оғ anything else for that matter). Not only should you have messages for 
verb-noun combinations that are essential for the game (all the "OK" and "YOUz TOOK THE 
GOLD" messages), but also for the more irrelevant or silly combinations, you make 
equally silly replies - for "SWING ROPE" you could reply "THIS IS NO TIME TO PLAY 
GAMES!" There is no reason why you shouldn't have as much fun writing the game as 
others have playing it! You might also like to have some interesting replies to the 
coarse language that some adventurers enter (Tsk Tsk) when they are finding the going 


hard. 
You should also be composing your room descriptions. These should contain all the 
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information the player needs to know about the room (except for the exits and the 
visible objects which are covered elsewhere, and anything the player needs to LOOK 
for). 

Once again, as with most other aspects of adventure game design, I can't tell you 


exactly what to do here .Check the room descriptions (or anything else for that matter) 
of other adventures but remember that most players prefer original adventures. You 
should be able to get a vague idea of the lengths that you should have for each 
description and perhaps the style. 

If you want to have longer descriptions the text really starts to chew up the 
memory. You may be able to squeeze longer descriptions in using a method of tokenising, 
which stores commonly used words or phrases in the data statements as single character 
tokens: (the inverse character set), in much the same way that programs are stored in 
BASIC. This allows for much longer descriptions in the available memory, but looking 
for common words, assigning a token for each and using these in the data statements is, 
to say the least, rather tedious. You may still think it is worthwhile because of the 
atmosphere a well written, but slightly longer, room description can add to a game. 
This method will be discussed in more detail in a later edition. Even if you do use 
this method, you must limit your descriptions to a length of 255 characters or less. 
Not only will longer descriptions leave little room on the screen for possible exits, 
visible objects, and a strength (or any other) rating, but they will also generate a 
"STRING TOO LONG ERROR" 

if you aren't going to use this method, you should note that most room descriptions 
can begin with the words "You are", followed by "In", "On", "At", "Near", or "By", then 
followed by "A", "An", "The" or "Some". You can therefore leave the "You are" out of the 
description and add it later on in the program, and substitute the next two words with 
a number, as was done in the demonstration program. If the third or fourth word of some 
descriptions are not one of those above, use a code for a blank - "" — instead. 

This just about brings to an end the discussion of designing your program. You 

should now be ready to start designing the program code. Yes, it's more planning! 
"I don't need to plan my programs," you might say. However, even if you can write all 
your other programs without planning, if you try this with an adventure, you will 
probably leave things out and make the program a tangled mess. Also you will have 
difficulty tracking down bugs (the ones that don't cause error messages) because you 
have forgotten exactly where you put that particular section, or that if you want to 
add some extras to the program, like sound effects, you might find that you have run 
out of line numbers. 

If you think that means you have to draw a flowchart, don't bother. I tried once, 
and it quickly began to resemble a bowl of spaghetti. Even if you manage the flowchart, 
it may be difficult to follow, or you could have a nervous breakdown when you discover 
for the forty second time that you left something out, and because there isn't any room 
for it, you have to throw it away and start again. You should instead split the program 
into manageable modules and plan each one separately. these are: - 

LOAD ANY MACHINE LANGUAGE ROUTINES INTO MEMORY. 


` BRANCH TO INITIALISATION SUBROUTINE: (The initialisation is placed at the end of the 
program because each time the program interpreter encounters a GOTO statement it goes 
back to the start of the program and looks through all the line numbers until it finds 
the right one. Ав this is only used once, considerable time is saved by placing it at 
the end of the program.) 

DISPLAY THE CURRENT LOCATION, EXITS, ETC. 

ACCEPT PLAYER INPUT AND PROCESS IT INTO VERB AND NOUN. 

DEAL WITH ANY INPUT THAT THE COMPUTER DOESN'T UNDERSTAND. 


GREAT FLOCK OF IF... THEN STATEMENTS BRANCHING TO VARIOUS VERB ROUTINES: (or if you 
have an Extended BASIC - some ON - GOSUB statements. Don’t ask me why the designers of 
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the VZ decided to mask this command when it was already present іп the ROM.) 


DEAL WITH ANY EVENTS THAT HAPPEN INDEPENDANT OF THE PLAYER'S ACTION: (For example, 
check to see if the player has died.) 


SCREEN DEALING WITH THE PLAYER QUITTING OR DYING. 
SUBROUTINE FOR PLAYER MOVEMENT. 


INDIVIDUAL SUBROUTINES FOR ALL OTHER VERBS. 


INITIALISATION: (Dimensioning arrays, etc) 


DATA STATEMENTS: (These are placed at the end of the program for the same reason as the 
initialisation.) 


Here are just a few extra hints for typing in your program. Structural programming 
enthusiasts will probably lynch me for saying a few of these, but our main concern is 
memory, and not readability. 


- Use multiple statement lines: This saves memory as each line takes five bytes just 
to exist. Somewhere around half - perhaps even more - of the lines in an adventure are 
IF... THEN statements so if you don't use them you will have to waste more memory 
repeating the condition several times, or have a program that leapfrogs all over the 
place (which structural programmers probably dislike even more.) 

For example: 
1790 IF(H-7562 OR H-7662) AND Е (44)20 AND C(1)=0 THEN R$-"HE TAKES IT": Е(64) =1: F(44)= 
+(44)-1: RETURN | 

If you didn't use a multi ¬ statement line here you would have to list the long set of 
conditions many times. 


— If you use REM statements, Don’t GOTO or GOSUB directly to that line: You will want 
to remove these eventually; either because you are running low on memory, or because 
you have finished the program and you don't want to make it too easy for peeping 
adventurers to cheat! When you do this, you don't need to mess around changing lines in 
order to avoid "UNDEF’D STATEMENT ERRORS." 


— Leave out LETs, unnecessary spaces, etc: Not only do these take up extra memory, but 
they also take up space in the 64 characters you can have for each line, meaning you 
have to start new lines which waste even more memory. 


In the next few editions, we will look at adding a load/ save feature to your game, 
and the tokenised room descriptions mentioned earlier, then we will examine each 
section of the program in detail. 












| ; 
VERBS 


Swe - 


——— 


HELP 
IN V 

GO 

СЕТ 
EXAMINE 
LOOK 
DROP 

‚ LEAVE 

|: OPEN 
READ 
UNLOCK - 
LIGHT 
UNLIGHT 


.... - 


å . 
ee اوی‎ ٠ e 


ma a marr e e ama e CR ee, 


aa 


WIND 
DIG 
GIVE 
WEAR, 
Kick 
EAT 
START 
PLACE 
wr ІШЕ, 


бы: E 


apwe مہ‎ 










EXTINGUISH 
Do | 


SECTION ONE 






































































































вітнасом, ЁА QW (лос) ad bi Y / f 13) 010! 
و سک‎ + /<// | | oon 
M (washing MACHINE) ' | 145) 0011 
A ۳ ۹ „ (1180010 
N 7ا‎ HALL WITH — 4 17)0100 
ENTRANCE ' | pe oF 4۹ | | 15) 1100 
yat OE IAW HAL ER 4M. EM dV T М a} O10) 
6 E с 20)010 | 
7 (WEND UP Manse) | УР mouse) 210110 
pace mTAI4I CUu 2) 1100 
ded жа / BY some Жж 1j 100 
| (0008) BUSHES (GARDEN GNOME) 24) 10? 
aw Ep | dw Е № «v 45) WO | 
(LARGE ROCK) 
(KEY) ( BoNE) (GASMASK) (START) 
NOUNS 
LUSTING P 
T SECTION TWO VERBS NOUNS 
бооқ NS WE LIST 
"m 
0 yc ТАРЕ 
STICKY TAPE со ROCK 
68۸511 GET . FOOD ) 
Е LEAVE STICK I TAPE 
71 ТУЕ DA TASETTE 
Bone EXAMINE ое 
LOOK 
KEY _ ET E 
BATTERIES ae сай 
1 ЕС TION 2 AT SAVE PROGRAM 
С ИМЕ) нта | Ди 
i 
т MAHINE |  movEMENT CODES 
FOLDER ) 0020 
г: | 
SeoksHELE 2) 040) 
BROTHER ) 0040 
HOME WORK % 4 
BUSHES д) 200 | 


, ۳ 
٥۷0۸۲۳۴ DRAWER. 


you NEED A | 


i “ НЕ 
НЯ УС” LOUNGE A SACIE Боов «Амр PIT ы К RE. 
| BEDROOM BOOKSHELF MOVEMENT copes 
E (РНЕ or coxa || WITH (SCHOOL FOLDER) әтер |) | o1! 
| er и) 
А REMOTE сокта) | - رم‎ ٣ : 2) 9 
T ( CAR A (LISTING) А 
i f блек Tape) 3) Il 5 
ko | | 4) 1o! 
T LAUNDRY . 5) ! 00 
Fie ENTRANCE TO dii. | ام‎ ۱ 
d 800485 WITH STEREO À , 7) o01) 
; 7 а) 0011 
| /4 n (ALS i yao) 00 Il 
| N N A e ROOM WITH чу مہ‎ ۵ 
HALL. 00669 Yee HEN LAVNORY 1 CATFLAP 12) 0000 
DOOR WEST TO | CATFLAP رر‎ ) 


| 
| 
a 
| 
|. 





ni ee ہہ پمموسو٭ےمحمہ‎ oe, 
x . 


! 


} 
- سے وس ےس میمت ہوم وہہ‎ л зл و ا ا‎ a rim RSS an RS aS A БИО ra eame —— нивы 
. 
А . * + ` d 
"We + 


GAMES COLUMN 


Back once more. Good to see VZDU hanging on whilst others have 
given up (chicked out!). As I'm sure all would know, the VZ's well of 
potential 15 still far from exhausted. Especially in the games 
department. 

Of course, as always, this column still suffers from a chronic 
Таси of contributions; It really doesn't take that much to send in 
one tip, question or high score. Please make the effort and don't let 
your VZ gather dust. 


The game to be reviewed this issue is a golden oldie but as of yet 
has not passed under my scrutiny. Ever heard of ........ 


PHAROAH'S TOMB (?) 


The name really does tell the story. Trapped by a cave in the 
quest of a lifetime lays before you. Do you dare to tackle the will 
of the mighty pharoah and discover his incredible treasures? YES? 
Well to do so you must recover an emerald, sapphire and a diamond if 
you wish some sort of a chance at it. 


The storyline for this sort of adventure is as old as anyone can 
remember (although this game probably started it). Still the creator 
(Andrew Alley) has packed his piece of software with fairly detailed 
descriptions of locations and an average vocabulary. Another plus is 
the very fast playsystem which reacts incredibly fast (VZ wise) to 
your input. 


One gripe I have about this game and most others is trying to get 
а LISU: Of what your character, {= Carrying. It 18 really annoying to 
have to type the word <INVENTORY> every time you wish to call up this 
list. A simple <I> command would really ease things a bit here. 


PHAROAH'S  TOMB makes for a pretty good game. Although average in 
most respects, it is detailed and BIG so it will last the typical 
adventurer a while. 


RATING: 

*Vocabulary: 6 and a half 
۱260 7 
*Atmosphere: 7 and a half 
*Lastability 8 

OVERALL A na TIC C I 7 and a half. 


HOT, HANDY & HELPFUL HINTS 


*Nag, nag, nag! That's all you seem to hear right? Well this is the 

result, an empty bit! Please, please, PLEASE send in hints and tips 

for your favourite or conquered games. While there's a space though, 
is anyone interested in helping compiling PD GAME HINT/SOLUTION lists? 
If so you know who to write to. 


QUESTIONS & QUERIES 


2 C'mon don't be shy and boring. Get that game problem of yours out 


A 











in tne open. There is always someone out there who has been there 
before. Don't leave this spot a boring trail of pleading dribble!!! 


PD-TAPE NOTE! 
YES, tapes are still very slow in returning but believe me the 
pace is quickening. I will try to squeeze in as much time as possible 


between studies and work for PD TAPES. Don't give up and keep 
checking your post box. 


Well as always I've run out of things to say for now. Please 
breathe life back into your remarkable VZ and write in now to the 
address below. 


"Til next time, see you next edition! 


Please send all your hints, high scores, questions and answers in 


to: 

Paul Frantz 

29 O5^OGKeY 9C 

KIRWAN QLD 4817 

mt 
The HIGH Scores 

DAWN PATROL 52500 David Wood 
CRASH 410 Harry Huggins 
DIG OUT 24400 Paul Frantz 
HAMBURGER SAM 39500 Stephen Frantz 
LADDER CHALLENGE 22130 Paul Frantz 
KAMIKAZE 6710 Stephen Frantz 
TEN PIN BOWLS 185 David Wood 
VZ INVADERS 13990 Mitch Pendlebury 
GALAXON 150000 Nicole Huggins 
PENGUIN 1350 Jason Oakley 
LUNAR LANDER 3600 Jason Oakley 
SUPER SNAKE 811 Tim Oliver 


In this issue we have the first item from David Wood on how to 
write Adventure Programs. There is still quite a bit to come. In fact 
about another 4 issues (8 months). As this is a long time to wait, a 
suggestion has been made that we let out a printout of it, on the same 
basis as our Back Issues. You can photo copy it, and return promptly. 
Write in and let us know your views. This would ofcourse have to have 
the approval of David, as he is the Copyright holder. It will NOT he 
put out on disk or tape. 


I think it а very good article, and we look forward to getting 
some more programmers contributing to your Newsletter. (Ed.) 


THESE LINES WERE MISSED IN LETTER TO EDITOR LAST ISSUE 

200 DATA 32,952,342, 90.45.50, 48 

210 DATA 32. 32. 32.68,69 65.82.32, 72709,8982 9 

220 DATA 32.32 65,76 76. 32. 84, 7/2. 69.32.66 69,83,84, 40, 292, 2 
230 DATA 82,46,72,46 








LETT INVESTIGATE SOUND ON THE VAZ“ 


PART II 
by Bob Kitch. 


Last time we produced the Star Wars Theme using a few simple BASIC 
commands. Let's analyze this action a little further and see what 
insight this gives us. Recall that there were a few shortcomings or 
limitations in using the SOUND command. 


SOUND COMMAND. 


Quite a lot happens in the BASIC Interpeter when the SOUND command 
is used. 


As the Command Interpeter is scanning through a line in the BASIC 
Program Statement Table, it is searching for the SOUND token 9EH. Upon 
finding this token, it transfers control to the Verb Action Routine 
for the SOUND command located at 2BFSH to 2C71H. Perhaps you would 
like to Disassemble this portion of your ROM and decode it? This 
section of code looks for the pitch and duration values in the Program 
Statement Table that form part of the command. 


Remember that these values must be in the range of 1 to 51 and 0 
to 9 respectively. The routine mentioned above, checks these values. 
Where does it pick up the correct frequency and duration to pulse the 
speaker? 


Two tables of values are embedded in the ROM. A Frequency Table 
occurs from O2CFH to O30CH. These are two-byte entries and correspond 
to the notes A2 to D#5. (31 notes and 62 bytes.) At O361H to 037FH 
another 31 byte table exists for the 31 tones. These values correct 
the duration for the frequency value read from the larger table. 


The Verb Action Routine then calls a couple more subroutines in 
ROM to switch bits О and 5 in the Output Latch at 6800H. These are the 
“low-level” routines that control the piezo speaker. We are now very 
close to the hardware of the VZ. 


The low-level code consists of three subroutines commencing at 
3450H to 3483H in ROM. Perhaps some more Disassembly would be 
illuminating at this point? The main routine is at 345CH to 3468H. On 
entry, the HL register contains the frequency, and the BC register 
contains the duration. The entry point from the Verb Action Routine is 
at 5459Н to 3483H where the "cycling" of the Output Latch occurs to 
achieve the sound. A third BEEP routine occurs from 3450H to 345BH. 
This section sets the HL register to 160 and the BC register to 6 to 
provide a beep. This sound is heard every time a key is pressed on the 
keyboard - so this routine is called quite often. 


SOUND EFFECTS PROGRAM. 


To illustrate some of these ideas, the accompanying program is 
useful. A series of sound effects are generated by manipulating the HL 
and BC registers of the Z80 and by calling the sound routine located 


i — 


VL. Be ہے‎ 


at S4S5CH іп ROM. Note that this is a distinctly different way of 
making а noise compared to the SOUND command in BASIC. Furthermore, 
note the variety of sounds that can be produced. The Sound Effects 
program is more "interesting" than the previous Star Wars melody. 


The Sound Effects program uses the USR() statement to connect the 
BASIC program to the ROM calls. It 15 an extremely useful and powerful 
technique. How many of you are familiar with it? It is poorly 
explained in the VZ Manuals. The 12 bytes of machine code are set out 
in lines 130 to 180. 


The program is also set out to illustrate the "looping" that 
occurs to place certain values into the HL and BC registers. This form 
of coding clarifies the procedures. 


Next time we will discuss directly switching the latch at 6800H 
using our own machine code routine - not the one's in ROM. Notice how 
we are "getting closer to the hardware" and obtaining more control 
over the sound output. 


> жжжжжжжжжжжжжжжжжжжжж ж 
> ж ж SOUND EFFECTS ж ж 
> жж LE Wz #10 ж ж 
> ж ж R. B.K. 307/17/86 жж 
> ж ж ALTERED 26/8/90 жж 
> KKRBK, ANDREW WILLOWS xX x 
> KKKEN CLARKE (NZ) ж ж 
> X oK OK OK OK OK oK OK OK OK OK oK OK OK OK OK OK OK OK OK OK K 
ЖЖЖЖЖРОКЕ IN M/L ROUTINEXKXXX 

FOR T%=-28687 TO -28676 :'POKE INTO 8FF1H TO 8FFCH. 
READ D%:POKE ТУ, DY, 

NEXT Т% 

РТУ--28685 :'ADDR. FOR PITCH (L-REG) 

DR%=-28682 :'ADDR. FOR DURATION (C-REG) 

DATA 229 :' PUSH HL 

DATA 033,160,000 :’ LD HL, OOAO PITCH 160 

DATA 001,003,000 :' LD BC,0003 DURATION 3 

DATA 205,092,052 :' CALL 345C 

DATA 225 :’ POP HL 

DATA 201 :’ RET 

POKE 30862, 241:POKE30863,143:’SET 788E/FH TO F1/8F FOR USR(). 


” XXX XXMAIN MENUXXXXX | 
CLS 

PRINT:PRINT" эй وم‎ жама тті 
PRINT МЕЙДІ ЫЕ] НЕ ا‎ | 








PRINT" а | 
PRINT" EEL a ن2‎ 27277121221 






РМТ" ٹا‎ Рта ШЕШШ mm ~ d um 
PRINT "ЕЕН | SR MED ا‎ m 


290 
320 

330 

340 

400 

410 

420 

430 

440 

450 

460 

470 

510 

1100 
1110 
1120 
1130 
1140 
1150 
1140 
1200 
1210 
1220 
1230 
1240 
1250 
1240 
1300 
1310 
1320 
1330 
1340 
1350 
1340 
1370 
1380 
1400 
1410 
1415 
1420 
1425 
1430 
1435 
1440 
1445 
1450 
1455 
1440 
1465 
1470 
1500 
1510 


1520 
1550 


1540 


1550 
1260 


Ы ^‏ و وم 


Vu -- ad os, 
- . -1- .. . » “ 1 к. =. 5 a ae 
APER MEM ee eae کے جح‎ og tele! ان جوم عم‎ 





PRINT@444, " ! 
PRINTG448,"ENTER OPTION # 
POKE DR%,3 | 


' XXXXXBRANCH. TO 
IF OP$="A",1100 
IF OP$="C",1300 
IF ОРФ-"Е",1500 
IF OP$="6",1700 
IF OP$="I", 1900 
IF ОРФ-"К",2100 
IF OP$="M", 2300 
GOTO320 


” XXXX*X*DECAYING 


"3: INPUT OPS : 
:'SET DURATION TO $ ON ENTRY. 
СНОІСЕЖЖЖЖЖ 


ELSE ОР%= "В", 1200 


ELSE IF ОР%= "р", 1400 
ELSE IF ОРФ= "Е", 1600 
ELSE IF ОР%= "Н", 1800 
ELSE IF ОР%="Ј", 2000 
ELSE IF ОР%= "1", 2200 
ELSE IF ОР%= "№", 210 
ZOOPXXXxxx 


CLS8:PRINTG232,"DECAYING ZOOP" 


FOR Т%=1 TO 255 STEP 4 


POKE РТУ, ТУ 
X=USR (0) 
NEXT T% 
GOTO 210 


:" LOWER PITCH - FIXED DURATION. 


"XXXXX INCREASING 2ООРЖЖЖЖЖ 
CLS:PRINT@232," INCREASING ZOOP" 


FOR ТЖ%=255 TO 1 STEP 


POKE РТУ, ТУ 
X=USR (0) 
NEXT TX 
GOTO 210 


-4 : RAISE PITCH - FIXED DURATION. 


"XXXXXRANDOM ВЕЕРЗЖЖЖЖЖ 
CLS:PRINTG234,"RANDOM BEEPS" 


POKE DR*,10 
FOR Y%=1 TO 50 


: ' CONSTANT DURATION. 
:"DO SO REPETITIONS - VARY PITCH. 


T%=RND (254) +1 


POKE PT%,TY% 
X=USR (0) 
NEXT ۷۷ 
GOTO 210 


" XXXXXWAVESXX*Xx*x*x 
CLS:PRINT@237, "WAVES" 


POKE 0К%,1 
FOR \%=1 TO 0 
FOR T%=1 TO 


:'FIX DURATION. 
:' DO 10 OSCILLATIONS. 


10 : LOWERING PITCH. 


POKE РТУ, ТУ, 


X=USR (О) 
NEXT T4 


FOR TA=SO TO 1 STEP -1 


;'RAISING PITCH. 


POKE РТУ, ТУ 


X-USR (0) 
NEXT TA 
NEXT Y 
GOTO 210 


” XXXXXINCREASING PHASORXX xxx 
CLS: PRINTG23O,"INCREASING PHASOR" 


FOR Үй-20 TO 1 
FOR TA=Y% 


TO 1 STEP -1 


STEP -1 :” INCREASE STARTING PITCH. 


:' DECREASE NUMBER OF TONES. 


POKE PT%,T% 


X-USR (O) 
NEXT ТЖ 


| 


кие. ЕЛІ . 2-0. 7 . 1‏ ہے Г a 40 Sv а. АР,‏ کی وہ کے 
SRC ha: aS ra pna rt Ses . : SEC ТОЯ‏ 
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1570 
1580 
1600 
1610 
1620 
1630 
1640 
1650 
1660 
1670 
1680 
1700 
1710 
1720 
1730 
1740 
1750 
1760 
1770 
1780 
1790 
1800 
1810 
1820 
1830 
1840 
1850 
1860 
1870 
1880 
1890 
1900 
1910 
1920 
1950 
1940 
1950 


1960 


1970 
1980 
1990 
2000 
2010 
2015 
2020 
2025 
2030 
| 5 
2040 
. 2045 
2050 
2055 
2060 
2100 
2110 


NEXT Y% a 
GOTO 210 А27, 
” XXXXXDEGREASING РНАЗОВЖЖЖЖЖ 
CLS:PRINTG230, "DECREASING PHASOR" 
FOR Y%=1 TO 20 . DECREASE STARTING PITCH. 
FOR T%=1 TO Y% :' INCREASE NUMBER OF TONES. 
POKE РТУ, ТУ, | 
X=USR (0) 
NEXT ТУ 
NEXT Y% 
GOTO 210 
' XXXXXUFO ۷ ۱۷ 
CLS:PRINTG233,"UFO LEAVING" 
TY=61 ‚ВЕТ PITCH. |. 
FOR D%=460 TO 1 STEP -1 .'DECREASE DURATION. 
POKE DRX,D* 
POKE РТУ, ТУ. 
THETA 1 
X-USR (О) 
NEXT DX 
GOTO 210 
" XXXXXUFO ۵۸۷۲ا‎ ۱۴ 
CLS:PRINT@233, "UFO LANDING" 
Т%=1 | :’ SET PITCH. 
FOR D%=1 TO 60 -' INCREASE DURATION. 
POKE DR%, 0% | 
POKE РТУ, ТУ 
ТЖ=Т%+1 7 
X=USR (0) 
NEXT 07 
GOTO 210 
' XXX XXBUZZERXOOCKK 
CLS:PRINTG236, "BUZZER" 
POKE DR%,3 
POKE PT%,60 
FOR Y%=1 TO 100 
X=USR (0) 
FOR D%=1 TO 5 
NEXT D% 
NEXT Y% 
GOTO 210 
' X XXXSHIP ВІКЕМЖЖЖЖЖ 
CLS: PRINTG234,"SHIP SIREN" 
POKE DR*,8 S'FIX DURATION. 
FOR Y%=1 TO 10 | .'DO 10 REPEATS. 
FOR T%=200 TO 80 STEP -8:'INCREASE TONE. 
POKE РТУ, ТИ 
X=USR (0) 
NEXT ТУ 
FOR 0%=1 TO 150 
NEXT D 
NEXT Y% 
GOTO 210 


:’LOWER PITCH. 


: RAISE PITCH. 


:’SOUND TONE 100 TIMES. 


:* SMALL DELAY. 


:'DELAY BETWEEN REPEATS. 


+ *X*XXEXBURGLAR GaLARMXXxxx 


CLS:PRINT@233, "BURGLAR ALARM" 


2120 POKE DR%,255 :’FIX DURATION TO МАХ. 
2130 FOR Y%=1 TO 5 ;'DO 5 CYCLES. 

2140 POKE PT%,50 :' TONE HI. 

2150 X=USR (0) 

2160 РОКЕ PT%, 40 "ТОМЕ LO. 

2170 X=USR (0) 

2180 NEXT ۷۷ 

2190 GOTO 210 

2200 'XXXXXPOLICE SIRENXXXXX 

2210 CLS:PRINT@233, "POLICE SIREN" 

2215 POKE DR%,9 :'FIX DURATION. 

2220 FOR Y%=1 TO S :' DO 5 REPEATS. 

2225 FOR T%=200 TO 80 STEP -4 

2230 POKE РТУ, ТУ :'FAST RISING PITCH. 
2235 X=USR (0) 

2240 NEXT TX 

2245 FOR T4-80 TO 200 

2250 POKE РТУ, ТУ :'SLOW FALLING PITCH. 
2255 X=USR (0) 

2260 NEXT TX 

2265 NEXT Y% 

2270 GOTO 210 

2500 'XXXXXTELEPHONE XXX X X 

2310 CLS:PRINT@234, "TELEPHONE" 

2315 POKE DR%,15 | :'FIX DURATION. 

2320 FOR YX-1 TO 5 :'DO 5 REPEATS. 

2325 FOR D%=1 TO 2 :' SOUND DOUBLE RING. 
2330 FOR T%=1 TO 8 :'DO В WARBLES. | 

2335 POKE PT%,100 :'LO TONE. 

2340 X=USR (О) 

2345 POKE PT%,50 :'HI ТОМЕ. 

2350 X=USR (0) | 

2355 NEXT T* 

2560 FOR TX-1TO 50 :'PAUSE BETWEEN DOUBLE RINGS. 
2365 . NEXT TY 

2370 NEXT D 

2375 FOR D%=1 TO 400 :'PAUSE BETWEEN REPEATS. 
2380 NEXT 0% سے‎ 

2385 NEXT ۷۷ 

2390 GOTO 210 


10000 CLS:PRINT"ERASING SOUNDS":ERA"SOUNDS" 
10010 PRINT"SAVING SOUNDS": SAVE" SOUNDS" 
10020 END 


This information was sent in 


HACKERS AND PIRATES. 


of interest to others. 


I have found the 


by Ben Hobson, who thinks it may be 


problem with SPRITE GENERATOR crashing things. In 


my case DOS. 


| І have not tried it, but possibly relocate DOS or Extended Basic 
directly after the SPRITE routines, as maybe Sprite Generator uses 
Hi-Mem, or it may alter ІХ or ІҮ registers. Therefor a complete 
rewrite of Sprite Generator or of EXT. BASIC may be needed. 
| | | i 


= ж ae 2 . - t -- ہے‎ 
- 4 с U. " r . s > i It "= =. in BLS + 1% 
Dm CATIEZTATCUM سب ےس‎ CT жай TM ^r А v 5 > و ایند نصمہ‎ pe —— —— = 5———————  'H——— a tee pe etr ےہ سو سے ہا چو‎ A Ee са دہ رج‎ TECH ammonia 
ENT TAT ST ЕТ" Cash p nah nS Ce. o NOXENT Pen aes pe Se er eei voee Ду FE ESE SERIE TOT үст ee қ. Барысы ыты ранда тартыл үраны Mec m دک ےیگ‎ Gee ee m و‎ RU ASTA ds RE т тү جع سح عو‎ OG 
2 ..27 TE ECCE o qae med Жл ПИ чы. Ош: УК а ہو‎ oe 4... $ Кы E Е К a, ا لی ا‎ A hS و‎ жшк ' Ы d tow : > кы 


TRADING POST 


Are available from 
Bob Kitch 
7 Eurella Str. | 
KENMORE _ оға. 4069 


FOR SALE 


PRINTER GP 100. VZ compatiable. New ribbon. $100. 
Apply Editor. | 


یدک en et te‏ کک —————————— ا ہچ و re me‏ یه جس ee‏ سے © Tct‏ 





TO SWAP: VZ 300 BOBS. (no case or keyboard), Joystick interface with 1 
joystick, 9 x 6116 2k RAM сһірѕ,::280А, 2716 EPROM, 2 x 482764 EPROMs, 
Plus various ICs, eg 7416138, 741s157. All chips are socketed (except 
480A, EPROMS) and are from a defunct microbee. (The VZ300 does not work but 


only needs a 014 i.c.. Perhaps a good one. a be desoldered from one of the 
-old-V2300s the Editor “has for. salé. `` о 


FOR: У2200 in working order. (with Or without keyboard) 

ТЕ this does not please you PLEASE contact. me. anyway as I have many other | 
goodies I will include to make the: deal. i 

Ben Hobson , P.O. BOX 255, 80777 2343 Or. lione .(067) 462076 after 4pm. 


4 | 54 | KEK 
OTHER V ri USER GROUPS 
H.V.V.Z.U.G ZEE o DISKMAG 
P.0.Box 161 М, ЫҢ S Р.О.Вох 600. 
JESMOND NSW.2299.  . Taree NSW. 2430. 
CENT.VIC.COMP.Club и BRISBANE VZUG 
.24 Breen St. - p 63 Tingalpa St. 


BENDIGO VIC: (3550 WYNUM West. Q'1d. 4178 





Graeme? Bywater 
Р.о. Box | ‘388 
YMA 16062 
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"What а дау! The computer broke 
down and we all had to think!" 
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